Status of work on AOP at the OCM group, APRIL

The OCM (Objects, Components, Models) group of the computer science department at Ecole des Mines de Nantes is interested in Aspect-Oriented Programming (AOP). This report is a collection of three short articles presenting work in progress at our lab. We focus on two approaches: AOP from a monitoring perspective (articles 1 and 2) and different approaches to achieve AOP weaving (article 3). Whereas separation of concern is a most relevant and powerful concept, there are still few dedicated tools to implement this notion. Recently, AspectJ [KIC01] provides a first practical solution by offering both a domain specific language for defining crosscuts and a corresponding code weaver. In this article, we argue that crosscutting is the key notion of AOP which sets it apart from other code structuring techniques. We present execution monitors as a very general and operational model for crosscuts. This model should help to design better crosscut languages and code weavers. Customer requests Controller Service s c=select_customer prepare service call Billing ? charge(c, s) call_service(s) We believe that crosscutting is the key notion of AOP. Crosscuts relate together different program points or execution points such that common functionality can be inserted there. Imagine a controller (cf. the illustration above) that is intended to make secure a communication between clients and servers which are not security-aware. A typical way to achieve this is to use a multi-step protocol such as the following: first select a customer request, second perform a (potentially) complex computation in order to authenticate the partners and finally call a service. In such an application, the last selected customer is not available when a service is called. However, this information is mandatory in order to upgrade the application such that the service (not the controller!) can bill the customer. A conventional solution to this problem is to propagate the customer identity by threading this piece of information through the complex computation code (e.g. add an extra argument to all functions implementing this code). An AOP-like solution is to define a billing crosscut that relates a customer request selection with the corresponding called service. Execution monitors can naturally be used to define such a crosscut: they can detect specific sequences of actions occurring in the monitored program (e.g. a customer selection followed by a service call), pause the program execution, perform an action (e.g. call a billing function) and afterwards resume the program. This example demonstrates that …